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(1) 



Real Party in Interest. 



The real party in interest is Enounce, Incorporated, the assignee of all right, title, 
and interest in and to the patent application. 

(2) Related Appeals and Interferences. 

There are no other pending appeals, interferences, or judicial proceedings known 
to Appellant, Appellant's legal representative or assignee which may be related to, or which will 
directly affect or be directly affected by or have a bearing on the Board's decision in the pending 
appeal. 

(3) Status of Claims. 

The latest Office Action (mailed October 6, 2009) was a final action. Claims 1-9, 
15-17 and 19-39 have been cancelled, and Claims 10-14 and 18 are all the pending claims in the 
present patent application. Claims 10-14 and 18 stand rejected, and they have been rejected at 
least twice. The rejection of Claims 10-14 and 18 is appealed. 

(4) Status of Amendment. 

No amendment was filed subsequent to the last rejection. 

(5) Summary of the Claimed Subject Matter. 

The inventions of the various claims solve an important problem that arises when 
streaming media over a non-deterministic delay network such as the Internet. As most Internet 
users are well aware, a client device which receives streaming media over the Internet often 
suspends presentation of the media because the client device has run out of data to present and 
must wait until more data arrives. The inventions provide methods of mitigating this by time- 
scale modifying the media at rates that depend, for example, on CPU availability. 
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The following briefly summarizes the independent claims and claims separately patentable 
(references to para, in the specification to U.S. Patent Publication 2004/0064576) 

Claims 10-11 and 13 stand or fall together on Issue 1 . Representative 
Independent Claim 10 relates to a method for playback of streaming media received over a 
non-deterministic delay network at a client device. Please refer to FIGs. 2 and 14-18 and to the 
following portions of the specification: para. [0016] to para. [0024], para. [0053] to [0054], para. 
[0122] and para. [00124] to para. [0132]. Para. [0024] states (the underlined sections of para. 
[0024] refer to embodiments of the invention): "It should be understood that some embodiments 
of the present invention can operate in numerous modes. For example, one embodiment of the 
present invention may operate in a mode that attempts to balance a data consumption rate with a 
data arrival rate. In this mode, the embodiment utilizes changes in playback rate to alter the data 
consumption rate, and as a result, the playback rate of material presented by the embodiment is 
determined by the data delivery rate of information from the source, for example, a media server. 
For convenience, this mode is referred to as "Rate Determined by Data Arrival' 1 mode . In 
another mode, an embodiment of the present invention: (a) monitors various system conditions 
and user input playback presentation rate requests; (b) computes or infers data arrival and 
departure rates; and (c) intervenes whenever a user request would cause data underflow or 
overflow in Capture Buffer 400 or a disruption in playback. For convenience, this mode is 
referred to as "Rate Restricted by Data Arrival' 1 mode ." Para. [0122] and [0124] teach one of 
ordinary skill in the art how to utilize the measure of CPU availability in the two modes 
identified in para. [0024]. Specifically, para. [0122] states: "It should be understood that some 
embodiments of the present invention described above relate to presentation systems whose 
playback rates are determined by the media source transmitting data. Specifically, the media 
source, for example, a server, can elect to send data faster or slower than normal; to cause a 
faster or slower playback rate provided by these embodiments of User System 300 . This mode 
was referred to above as the "Rate Determined by Data Arrival" mode. It should be understood 
that the data arrival rate is not the only metric which can be utilized to determine presentation or 
playback rate. As described above other system metrics, such as CPU availability, may also be 
used . (Emphasis added)" Further, para. [0124] states: "Additionally, some embodiments of the 
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present invention described above relate to presentation systems wherein a determination is made 
of maximum and minimum presentation rates that are allowable to provide continuous and 
uninterrupted playback of media existing locally on a storage device or transmitted from a 
remote storage device via a communication medium. In accordance with these embodiments, the 
maximum and minimum presentation rates may be used with other information to prevent users 
of a variable rate presentation system from specifying presentation rates (playback rates) that are 
outside ranges of rates for continuous and uninterrupted playback. This mode was referred to 
above as the "Rate Restricted by Data Arrival M mode. It should be understood that the data 
arrival rate is not the only metric which can be utilized to determine presentation or playback 
rate. As described above other system metrics, such as CPU availability, may also be used to 
prevent interruptions in playback . (Emphasis added)" User interaction is described in para. 
[0053] and [0054] as follows: "[0053] As shown in FIG. 2, embodiment 1000 optionally 
comprises User Interface 900 for operating in "Rate Restricted by Data Arrival" mode in which 
User Interface 900 receives user generated rate requests in accordance with any one of a number 
of methods which are well known to those of ordinary skill in the art. The user generated rate 
requests are applied as input to TSM Rate Determiner 700. These user generated rate requests 
may be "folded" into the playback rates determined by TSM Rate Determiner 700 to provide 
continuous playback of streaming media. This means that these requests may be ignored or 
modified when they would interfere with the objective of providing continuous playback. The 
term "folded" means that requests from User Interface 900 may be overridden to prevent 
overflow or underflow of Capture Buffer 400. [0054] In accordance with an embodiment of this 
mode, if a requested playback rate (RPR) received from User Interface 900 exceeds CmaxSR, 
the request may be acknowledged by updating a position of RPR displayed in User Interface 900 
(to be described in detail below), but the rate output by TSM Rate Determiner 700 to TSM 
Subsystem 800: (a) may be limited to CmaxSR; or (b) may be determined by using any one of a 
number of algorithms that give precedence to rates which prevent underflow and overflow of 
Capture Buffer 400. For example, CmaxSR and equations (2), (3), and (4) set forth below may 
be used as follows. Whenever a user inputs a new RPR: (a) the new RPR value is compared with 
CmaxSR; and (b) a playback rate is determined using equations 2, 3, and 4 below. If RPR 
exceeds the lesser of CmaxSR and the playback rate from these equations, the lesser value is 
used. Similarly: (a) the new RPR value is compared with CminSR; and (b) a playback rate is 
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determined using equations 2, 3, and 4 below. If RPR is below the higher of CmaxSR and the 
playback rate from these equations, the higher value is used. Thus, in accordance with this 
embodiment, the rate output to TSM Subsystem 800 will stay within a range of values designed 
to prevent overflow and underflow of Capture Buffer 400." Lastly, display of time-scale 
modification rates is described in para. [0125] to para. [0132]. In particular, para. [0125] states: 
"In one embodiment of the "Rate Restricted by Data Arrival" mode of the present invention, 
User Interface 900 may comprise a graphical interface which provides a graphical presentation 
of Current Playback Rate (CPR), Requested Playback Rate (RPR), Current Maximum 
Sustainable Rate (CmaxSR), Current Minimum Sustainable Rate (CminSR). These are 
displayed graphically to the user in FIG. 14 as CPR 910, RPR 920, CminSR 930, and CmaxSR 
940. It should be understood that the graphical interface described may also be presented to 
users operating in the "Rate Determined by Data Arrival" mode." 

Claim 12 stands or falls by itself on Issue 1 , Claim 12 relates to the method of 
Claim 10 and includes the further element: "wherein playing back comprises associating a time- 
scale modification playback rate with each entry in a playback buffer queue." Please refer to the 
following portion of the specification. Para. [0025] states: "In some embodiments, the playback 
rate will be altered in a continuous, for example, slowly varying, fashion. For example, in some 
embodiments, buffers of time-scale modified output may be queued for playback in Playback 
System 500. In this case, the queued data may not be modified when a user requests a change in 
playback rate. As a result, whenever a user requests a change in playback rate, there may be a 
delay between the time the request is made and the time the change in playback rate is effected. 
This is because, in these embodiments, although time-scale modification may begin immediately 
for data sent to Playback System 500 after the request for a change in playback rate was 
received, there may be a delay until data processed with the previous rate (and buffered for 
output) has been played back. For this reason, such embodiments may appear to be a bit 
sluggish. To mitigate this perception, in accordance with one aspect of such embodiments, 
feedback is provided to the user to indicate a Current Playback Rate (CPR) and a Requested 
Playback Rate (RPR). CPR and RPR show the user that a newly requested playback rate has 
been received and that the embodiment is initiating a response. Advantageously, such feedback 
mitigates a tendency the user might have to "overcorrect" in an effort to elicit a salient response 
from any embodiment in which it is utilized. In a preferred embodiment of this aspect of the 
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present invention, the playback rate of each buffer of data available to Playback System 500 is 
associated with the buffer (this can be done by TSM Subsystem 800 or by other components of 
User System 300). Thus, when such buffers are presented (or are expected to be presented), 
User Interface 900 is provided an indication of the event of presentation of the buffer to the user 
(or expected event of presentation of the buffer to the user). In addition, User Interface 900 is 
presented the playback rate for the associated buffer or information that can be used to obtain the 
playback rate. For example, Playback System 500 may report the playback rate associated with 
each buffer as the buffer is played back. Alternatively, Playback System 500 may report the 
event of presentation of each buffer, and User Interface 900 or TSM Rate Determiner 700 may 
access a table which contains playback rates for each buffer that was dispatched to Playback 
System 500. This playback rate information is used to determine CPR and report it to the user, if 
desired. For example, in one embodiment, CPR is determined to be the playback rate of the most 
recent buffer played back. In other embodiments, CPR may be computed using any of several 
mathematical functions, for example, a mathematical average, of multiple values of playback 
rates of a predetermined number of the buffers played. Furthermore, in accordance with some 
embodiments that display RPR and CPR, the user receives confirmation of his/her request and is 
able to observe the embodiment's response. In operation, CPR will follow or chase RPR as the 
embodiment responds to user playback rate requests. As discussed above, such feedback may be 
useful to avoid overcorrections by users when the embodiment's response to user requests 
appears sluggish." 

Claim 14 stands or falls by itself on Issue 1 . Claim 14 relates to the method of 
claim 10 and includes the further element: "wherein the step of utilizing comprises ignoring or 
modifying the user input time-scale modification playback rate when it would interfere with 
providing continuous playback." Please refer to FIG. 2 and the following portion of the 
specification. Para. [0053] states: "As shown in FIG. 2, embodiment 1000 optionally comprises 
User Interface 900 for operating in "Rate Restricted by Data Arrival" mode in which User 
Interface 900 receives user generated rate requests in accordance with any one of a number of 
methods which are well known to those of ordinary skill in the art. The user generated rate 
requests are applied as input to TSM Rate Determiner 700. These user generated rate requests 
may be "folded" into the playback rates determined by TSM Rate Determiner 700 to provide 
continuous playback of streaming media. This means that these requests may be ignored or 
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modified when they would interfere with the objective of providing continuous playback. The 
term "folded" means that requests from User Interface 900 may be overridden to prevent 
overflow or underflow of Capture Buffer 400."; and para. [0054] states: "In accordance with an 
embodiment of this mode, if a requested playback rate (RPR) received from User Interface 900 
exceeds CmaxSR, the request may be acknowledged by updating a position of RPR displayed in 
User Interface 900 (to be described in detail below), but the rate output by TSM Rate Determiner 
700 to TSM Subsystem 800: (a) may be limited to CmaxSR; or (b) may be determined by using 
any one of a number of algorithms that give precedence to rates which prevent underflow and 
overflow of Capture Buffer 400. For example, CmaxSR and equations (2), (3), and (4) set forth 
below may be used as follows. Whenever a user inputs a new RPR: (a) the new RPR value is 
compared with CmaxSR; and (b) a playback rate is determined using equations 2, 3, and 4 
below. If RPR exceeds the lesser of CmaxSR and the playback rate from these equations, the 
lesser value is used. Similarly: (a) the new RPR value is compared with CminSR; and (b) a 
playback rate is determined using equations 2, 3, and 4 below. If RPR is below the higher of 
CmaxSR and the playback rate from these equations, the higher value is used. Thus, in 
accordance with this embodiment, the rate output to TSM Subsystem 800 will stay within a 
range of values designed to prevent overflow and underflow of Capture Buffer 400." 

Claim 18 stands or falls by itself on Issue 1 . Independent Claim 18 relates to a 
method for playback of streaming media received over a non-deterministic delay network at a 
client device. Please refer to FIG. 2 and to the following portions of the specification: para. 
[0016] to para. [0024], para. [0122] and para. [00124] in light of the summary for Claim 10 
above. 

(6) Grounds of Rejection to be Reviewed on Appeal. 

1. Whether Claims 10-14 and 18 are patentable under 35 U.S.C. § 103(a) 
over Gupta (U.S. Publication No. 2002/0038374 Al) in view of Hoyer et 
al. (U.S. Patent No. 6,381,635). 
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(7) 



Argument. 



Issue I : Whether Claims 10-14 and 18 are patentable under 35 U.S.C. § 103(a) over 
Gupta et al. (U.S. Publication No. 2002/0038374 Al) in view of Hover et ah 
(U.S. Patent No. 6,381,635). 

Claim Groupings for Issue I: 

Issue 1, Grp. 1: Claims 10-11 and 13 stand or fall together on this ground 

of rejection, the Representative Claim of Group 1 is Claim 
10. 

Issue 1, Grp. 2: Claim 12 stands or falls by itself on this ground of 

rejection. 

Issue 1, Grp. 3: Claim 14 stands or falls by itself on this ground of 

rejection. 

Issue 1, Grp. 4: Claim 18 stands or falls by itself on this ground of 

rejection. 

Reasons why Issue 1, Grp. 1 Claims 10-11 and 13 are separately patentable 

Appellants respectfully submit that Representative Claim 10 of Group 1 and 
Claims 11 and 13 of Group 1 are separately patentable from the claims of the other Groups 
because Representative Claim 10 of Group 1 requires "determining a time-scale modification 
playback rate considering the measure of CPU availability and user input time-scale modification 
playback rate requests" and "providing an indication of a current time-scale modification 
playback rate to the user." 

Reasons why Issue 1, Grp. 2 Claim 12 is separately patentable 

Appellants respectfully submit that Claim 12 of Group 2 is separately patentable 
from the claims of the other Groups because, although Claim 12 of Group 2 depends from 
Representative Claim 10 of Group 1, Claim 12 of Group 2 further requires "wherein playing 



-7- 



back comprises associating a time-scale modification playback rate with each entry in a playback 
buffer queue." 

Reasons why Issue 1, Grp. 3 Claim 14 is separately patentable 

Appellants respectfully submit that Claim 14 of Group 3 is separately patentable 
from the claims of the other Groups because, although Claim 14 of Group 3 depends from 
Representative Claim 10 of Group 1, Claim 14 of Group 3 further requires "wherein the step of 
utilizing comprises ignoring or modifying the user input time-scale modification playback rate 
when it would interfere with providing continuous playback." 

Argument Regarding Issue 1, Grp. 1 Claims 10-11 and 13 

In the final Office Action of October 6, 2009, the Examiner 
asserted (although the Examiner used the Gupta et al. publication 
as a reference, she apparently cited locations below from Gupta et 
al. U.S. Patent No. 6,622,171): 

As per claim 10, Gupta teaches a method for playback of 
streaming media received over a non-deterministic delay network 
at a client device which comprises receiving the streaming media 
at the client device, which client device includes a CPU (figure 1 
and col. 7, lines 38-50); playing back the streaming media; 
determining a time-scale modification rate considering one user 
input time-scale modification to prepare the streaming media for 
playback (col. 6, lines 39- 48, user input is used for timeline 
modification changes and rate for playback at the client device and 
col. 6, lines 63-col. 7, lines 1-3); and providing an indication of a 
current time-scale modification playback rate to the user (Figure 5, 
col. 10, lines 23-30). 

Gupta does not explicitly teach determining a measure of 
CPU availability. 

However Hoyer teaches determining a measure of CPU 
availability (col. 7, lines 10-21). 

Accordingly, it would have been obvious to one of ordinary 
skill in the networking art at the time the invention was made to 
have incorporated Gupta's teachings to the teachings of Hoyer, for 
the purpose of routing request to client servers that are active and 
available (i.e. servers that have not failed or are in standby mode, 
col. 7, lines 10-21). 

As per claim 11, Gupta- Hoyer teaches a method that further 
comprises steps of providing an indication of a user requested 
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time-scale modification playback rate (Figure 5, col. 10, lines 23- 
30). 

As per claim 12, Gupta- Hoyer teaches wherein the step of 
playing back comprises associating a time-scale modification 
playback rate with each entry in a playback buffer queue (col. 10, 
lines 53-62). 

As per claim 13, Gupta-Hoyer teaches wherein the 
indication comprises a function of recent time-scale modification 
playback rates (col. 10, lines 53-62). 

As per claim 14, Gupta-Hoyer teaches wherein the step of 
utilizing comprising ignoring or modifying the user input time- 
scale modification playback rate when it would interfere with 
providing continuous playback (col. 8, lines 40-44). 

As per claim 18, Gupta teaches a method for playback of 
streaming media received over a non-deterministic delay network 
at a client device which comprises steps of: receiving the streaming 
media at the client device, which client device includes a CPU; 
playing back the streaming media; determining a time-scale 
modification playback rate as a function of the measure and 
utilizing time- scale modification to prepare the streaming media 
for playback (col. 6, lines 39-48, user input is used for timeline 
modification changes and a time- scale modification speed is 
designated from the user for playback at the client device and col. 
6, lines 63-col. 7, lines 1-3). 

Gupta does not teach determining a measure of CPU 
availability. 

However, Hoyer teaches determining a measure, where the 
measure is of CPU availability (col. 7, lines 10-21). 

Refer to the motivation of claim 10 which applies equally 
as well to claim 18. 

Discussion of Gupta et al. 

Appellants submit that Gupta et al. teaches a method that is completely different 
from the invention of Representative Claim 10. 

Gupta et al. teaches methods of streaming multimedia content over a network, 
which methods support user- specified timescale modification. The Abstract of Gupta et al. 
states: "Multimedia content is streamed over a network system from a server computer to a client 
computer. The client allows a user to enter a variable playback speed and varies the speed at 
which the multimedia content is rendered at the client. Time- scale modification technology is 
used to maintain the original pitch of any audio content, thereby maintaining its intelligibility." 
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As set forth in paragraph [0009] in the Summary of the Invention of Gupta et al.: 

The invention utilizes time-scale modification so that a user 
can vary the speed of streaming content without destroying its 
intelligibility. In accordance with the invention, a user selects 
multimedia content from a menu presented at a network client 
computer. In addition, the user selects a speed factor, indicating 
the speed at which the multimedia should be rendered relative to 
its default speed. 

Further, at paragraph [0012], Gupta et al. teaches how to deal with limited 
bandwidth situations: 

The invention includes methods of adapting to limited 
bandwidth situations by composing or selecting composite streams 
having differing degrees of quality, and/or by composing or 
selecting streams with timelines that are altered to closely 
correspond with whatever speed factor has been chosen. In one 
embodiment of the invention, certain media streams, such as audio 
streams, take precedence over other streams such as video streams. 
In this embodiment of the invention, the audio stream is sent with 
an unaltered timeline, at a rate sufficient to satisfy the consumption 
requirements of the client, given the current speed factor. The 
video is then degraded in quality to reduce its bandwidth, so that it 
can be streamed in whatever bandwidth is not require by the audio. 

Lastly, Gupta et al. teaches the following with respect to interruptions in 
streaming at paragraph [0061]: 

In the described embodiment, the user is allowed to change 
the speed designation during rendering of the composite media 
stream. In some cases, however, it may not be possible to change 
the playback speed without interrupting the playback momentarily. 
If this is the case, playback resumes as soon as possible, beginning 
at a point that shortly precedes the point at which playback was 
discontinued . Thus, there is some overlap in the presentation— 
when the presentation resumes, the overlap provides context for 
the new content that follows. (Emphasis added) 

As the Board can appreciate from the above, Gupta et al. does not teach how to 
mitigate a problem that occurs when a client device has run out of data to present (due to non- 
deterministic delays in the network) and must wait until more data arrives. Hence, Gupta et al. 
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does not even address the problem solved by the invention of Representative Claim 10. Because 
of this, the method disclosed in Gupta et al. leaves the user with interrupted playback. In fact, as 
set forth above, Gupta et al. only teaches dealing with a problem of limited bandwidth by 
preparing multiple streams having different degrees of quality. Appellants respectfully submit 
that the teaching of Gupta et al. in this regard is completely different from the invention of 
Representative Claim 10. 

Differences between Gupta et al. and the Invention of Representative Claim 10 

Appellants respectfully submit that one of ordinary skill in the art would 
understand that Gupta et al. teaches a method for playback of streaming media received over a 
non-deterministic delay network at a client device that is completely different from the invention 
of Representative Claim 10. Appellants submit that the teaching of Gupta et al. is completely 
different from the invention of Representative Claim 10 for a number of reasons. 

Reason 1 : Representative Claim 10 requires determining a time- scale 
modification playback rate considering the measure of CPU availability and user input time-scale 
modification playback rate requests whereas Gupta et al. teaches determining a time-scale 
modification playback rate only using a time-scale modification playback rate provided by user 
input. 

Reason 2 : Gupta et al. does not teach how to mitigate a problem that occurs 
when a client device runs out of data to present (due to non-deterministic delays in the network) 
and must wait until more data arrives. In fact, as set forth above, Gupta et al. only teaches how 
to deal with a problem of limited bandwidth by preparing multiple streams having different 
degrees of quality. Preparing multiple streams having different degrees of quality in accordance 
with the teaching of Gupta et al. is completely different from the invention of Representative 
Claim 10 which uses a measure of CPU availability and user input time- scale modification 
playback rate requests to determine a time-scale modification playback rate. 

Reason 3 : Gupta et al. teaches that "In some cases, however, it may not be 
possible to change the playback speed without interrupting the playback momentarily." In other 
words, Gupta et al. teaches no action beyond the user waiting for the interruption to end. This is 
completely different from the invention of Representative Claim 10 which uses a measure of 
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CPU availability and user input time- scale modification playback rate requests to determine a 
time-scale modification playback rate. 

In sum , there is no hint or suggestion or even common sense reason that would 
cause a person of ordinary skill in art who read Gupta et al. to use a measure of CPU availability 
in any manner whatsoever, let alone to determine a time-scale modification playback rate in 
accordance with Representative Claim 10. In fact, there is no hint or suggestion or even 
common sense reason that would cause a person of ordinary skill in art who read Gupta et al. to 
have any expectation that a measure of CPU availability would have any use in mitigating the 
problem caused by a non-deterministic delay network. As such, Appellants respectfully submit 
that a person of ordinary skill in the art who read Gupta et al. would be completely surprised by 
the unexpected result that using a measure of CPU availability to determine a time- scale 
modification playback rate would be useful in addressing the problem caused by a non- 
deterministic delay network. 

Discussion of Hover et al. 

Hoyer et al. teaches a method for displaying multiple performance measurements 
of a web site. As set forth in Hoyer et al. at col. 2, lines 16-28: 

The present invention greatly enhances the administrator's 
ability to analyze and understand a web site's performance by 
providing a display method that makes it easy to visualize the 
interrelationships between various performance measurements. 

The present invention provides a compact mechanism for 
displaying multiple web performance graphs that allows the 
administrator to easily focus in on one or more performance 
measurements. The three key components of the present invention 
are 1) colored vertical scale buttons, 2) variable thickness colored 
graphs, and 3) colored legend buttons that can show or hide a 
particular graph. 

In addition, Hoyer et al. states the following regarding CPU utilization at col. 7, 

lines 52-55: 

(3) CPU Utilization: is the number that represents the 
percentage of time that the CPU is doing useful work on a node 
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running a web server. For web sites, it is the average of the node's 
CPU utilization numbers. 

In further addition, Hoyer et al. states the following regarding CPU utilization at 
col. 18, lines 24-40: 

As depicted in FIG. 7, three performance graphs are 
depicted with one of the three graphs having been selected and this 
selected graph 735 is drawn three times thicker than the other 
graphs for emphasis to the administrator. The graph has a time- 
line, as depicted, which extends from 0 seconds to 48 seconds. 
The three performance graphs include hit rates (three hits per 
second displayed in box 740), response time (904 milliseconds 
displayed in box 745) and percentage CPU usage (53% displayed 
in box 750). In the lower left hand corner of the server view is a 
legend including three toggle icons or buttons, button 760 for 
hits/second, button 770 being for response time, and button 780 
being for CPU utilization. By clicking on a particular toggle 
button 760, 770, 780, a particular performance measurement graph 
can be shown or hid. When a performance measurement graph is 
hidden, its corresponding legend level is grayed. 

As the Board can readily appreciate from the above, Hoyer et al. does not teach or 
suggest using CPU utilization for any purpose whatsoever other than to display it. 

Discussion of the combination of Gupta et al. and Hover et al. 

Appellants submit that there is no suggestion or motivation of any kind to 
combine the teachings of Gupta et al. and Hoyer et al. in any way whatsoever since Gupta et al. 
teaches absolutely nothing regarding a measure of CPU availability and Hoyer et al. only teaches 
obtaining and displaying CPU utilization and Hoyer et al. nothing concerning any use of CPU 
utilization. However, Appellants respectfully submit that even if a person of ordinary skill in the 
art were to combine Gupta et al. and Hoyer et al., that person would not arrive at the invention of 
Representative Claim 10 because there is nothing in either reference that teaches or hints in any 
way or even provides a common sense reason for determining a time- scale modification 
playback rate by considering a measure of CPU availability and user input time-scale 
modification playback rate requests as required by Representative Claim 10 and the other claims 
in Group 1. As set forth above, Gupta et al. teaches absolutely nothing regarding a measure of 
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CPU availability and Hoyer et al. only teaches obtaining and displaying CPU utilization and 
nothing concerning any use thereof. In fact, if one of ordinary skill in the art were to combine 
Gupta et al. and Hoyer et al., that person might display CPU utilization or that person might 
generate alternative versions of the media being rendered that took less CPU utilization to 
present. Both of these methods do not teach or suggest the invention of Representative Claim 10 
or of the other claims in Group 1. 

In discussing obviousness and obtaining a "predictable result" the court in 
Sundance, Inc. v. Demonte Fabricating Ltd. , 550 F.3d 1356 (Fed. Cir. 2008) stated the following 
at 1366-67: 

"[I]n many cases a person of ordinary skill will be able to 
fit the teachings of multiple patents together like pieces of a 
puzzle." KSR* 127 S. Ct. at 1742 . Such a combination is more 
likely to be obvious where it "'simply arranges old elements with 
each performing the same function it had been known to perform' 
and yields no more than one would expect from such an 
arrangement." Id. at 1740 (quoting Sakraida v. AG Pro, Inc., 425 
U.S. 273, 282, 96 S. Ct. 1532, 47 L. Ed. 2d 784 (1976)) . 

Appellants submit that the use of a measure of CPU availability to determine a 
time-scale modification playback rate to mitigate the problem caused by a non-deterministic 
delay network is surprising and unpredictable . Further, here is no teaching or hint or 
suggestion of any kind in Gupta et al. or Hoyer et al. that this surprising and unpredictable result 
could be obtained or even how it could be obtained. 

In light of the above, Appellants respectfully submit that Issue 1, Grp. 1 Claims 
10-11 and 13 are patentable over Gupta et al. in view of Hoyer et al. 

Argument Regarding Issue 1, Grp. 2 Claim 12 

Claim 12 depends from claim 10, and as such, the arguments set forth above with 
respect to Claim 10 are incorporated herein. In addition, Appellants respectfully submit that 
neither Gupta et al. nor Hoyer et al. teaches or suggests in any manner whatsoever the following 
element of Claim 12: "wherein playing back comprises associating a time-scale modification 
playback rate with each entry in a playback buffer queue." In further addition, Appellants 
respectfully submit that the Examiner was incorrect when she asserted: "Gupta-Hoyer teaches 
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wherein the step of playing back comprises associating a time-scale modification playback rate 
with each entry in a playback buffer queue (col. 10, lines 53-62)." At col. 10, lines 53-62, Gupta 
et al. states: "Menu 264 lists multiple playback speeds from which a user can select. In the 
illustrated example, five playback speeds are listed: x0.5, x0.75, xl.O, xl.25, and xl.5. The user 
can select one of the listed speeds to instruct the multimedia player to play the multimedia 
content at a desired speed. As noted above, the user can select a new speed after the content has 
begun playing by invoking the menu and selecting the new speed. In response, the multimedia 
player repeats a portion of the multimedia content and begins playing at the new speed." Thus, 
nothing having anything to do with "associating a time-scale modification playback rate with 
each entry in a playback buffer queue" appears at col. 10, lines 53-62 of Gupta et al. Thus, 
Appellants respectfully submit that Claim 12 is patentable over the combination of Gupta et al. 
and Hoyer et al. because, even if Gupta et al. and Hoyer et al. were combined, that combination 
would not arrive at the invention of Claim 12 since the combination would be missing at least the 
above-identified element. 

In light of the above, Appellants respectfully submit that Issue 1, Grp. 2 Claim 12 
is patentable over Gupta et al. in view of Hoyer et al. 

Argument Regarding Issue 1, Grp. 3 Claim 14 

Claim 14 depends from claim 10, and as such, the arguments set forth above with 
respect to Claim 10 are incorporated herein. In addition, Appellants respectfully submit that 
neither Gupta et al. nor Hoyer et al. teaches or suggests in any manner the following element of 
Claim 14: "wherein the step of utilizing comprises ignoring or modifying the user input time- 
scale modification playback rate when it would interfere with providing continuous playback." 
In further addition, Appellants respectfully submit that the Examiner was incorrect when she 
asserted: "As per claim 14, Gupta-Hoyer teaches wherein the step of utilizing comprising 
ignoring or modifying the user input time- scale modification playback rate when it would 
interfere with providing continuous playback (col. 8, lines 40-44)." At col. 8, lines 40-44, Gupta 
et al. states: "In the described embodiment, the user is allowed to change the speed designation 
during rendering of the composite media stream. In some cases, however, it may not be possible 
to change the playback speed without interrupting the playback momentarily. If this is the case, 
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playback resumes as soon as possible, beginning at a point that shortly precedes the point at 
which playback was discontinued. Thus, there is some overlap in the presentation-- when the 
presentation resumes, the overlap provides context for the new content that follows." Thus, as 
can be seen from col. 8, lines 40-44 of Gupta et al. that Gupta teaches the opposite of "ignoring 
or modifying the user input time- scale modification playback rate when it would interfere with 
providing continuous playback"; namely, Gupta et al. teaches using the user input and being 
interrupted. Thus, Appellants respectfully submit that Claim 14 is patentable over the 
combination of Gupta et al. and Hoyer et al. because, even if Gupta et al. and Hoyer et al. were 
combined, that combination would not arrive at the invention of Claim 14 since the combination 
would be missing at least the above-identified element. 

In light of the above, Appellants respectfully submit that Issue 1, Grp. 3 Claim 14 
is patentable over Gupta et al. in view of Hoyer et al. 

Argument Regarding Issue 1, Grp. 4 Claim 18 

Discussion of Gupta et al. 

Appellants submit that Gupta et al. teaches a method that is completely different 
from the invention of Representative Claim 18. Appellants incorporate the discussion of Gupta 
et al. set forth above in the Argument regarding Issue 1, Group 1 by reference herein. 

Differences between Gupta et al. and the Invention of Representative Claim 18 

Appellants respectfully submit that one of ordinary skill in the art would 
understand that Gupta et al. teaches a method for playback of streaming media received over a 
non-deterministic delay network at a client device that is completely different from the invention 
of Representative Claim 18. Appellants submit that the teaching of Gupta et al. is completely 
different from the invention of Representative Claim 18 for a number of reasons. 

Reason 1 : Representative Claim 18 requires determining a time- scale 
modification playback rate as a function of the measure of CPU availability whereas Gupta et al. 
teaches determining a time-scale modification playback rate only using a time-scale modification 
playback rate provided by user input. 
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Reason 2 : Gupta et al. does not teach how to mitigate a problem that occurs 
when a client device runs out of data to present (due to non-deterministic delays in the network) 
and must wait until more data arrives. In fact, as set forth above, Gupta et al. only teaches how 
to deal with a problem of limited bandwidth by preparing multiple streams having different 
degrees of quality. Preparing multiple streams having different degrees of quality in accordance 
with the teaching of Gupta et al. is completely different from the invention of Representative 
Claim 18 which determines a time- scale modification playback rate as a function of a measure of 
CPU availability. 

Reason 3 : Gupta et al. teaches that "In some cases, however, it may not be 
possible to change the playback speed without interrupting the playback momentarily." In other 
words, Gupta et al. teaches no action beyond the user waiting for the interruption to end. This is 
completely different from the invention of Representative Claim 18 which determines a time- 
scale modification playback rate as a function of a measure of CPU availability. 

In sum , there is no hint or suggestion or even common sense reason that would 
cause a person of ordinary skill in art who read Gupta et al. to use a measure of CPU availability 
in any manner whatsoever, let alone to determine a time-scale modification playback rate in 
accordance with Representative Claim 18. In fact, there is no hint or suggestion or even 
common sense reason that would cause a person of ordinary skill in art who read Gupta et al. to 
have any expectation that a measure of CPU availability would have any use in mitigating the 
problem caused by a non-deterministic delay network. As such, Appellants respectfully submit 
that a person of ordinary skill in the art who read Gupta et al. would be completely surprised by 
the unexpected result that which determining a time-scale modification playback rate as a 
function of a measure of CPU availability would be useful in addressing the problem caused by a 
non-deterministic delay network. 

Discussion of Hover et al. 

Appellants incorporate the discussion of Hoyer et al. set forth above in the 
argument regarding Issue 1, Group 1 by reference herein. 

Discussion of the combination of Gupta et al. and Hover et al. 
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Appellants submit that there is no suggestion or motivation of any kind to 
combine the teachings of Gupta et al. and Hoyer et al. in any way whatsoever since Gupta et al. 
teaches absolutely nothing regarding a measure of CPU availability and Hoyer et al. only teaches 
obtaining and displaying CPU utilization and Hoyer et al. nothing concerning any use of CPU 
utilization. However, Appellants respectfully submit that even if a person of ordinary skill in the 
art were to combine Gupta et al. and Hoyer et al., that person would not arrive at the invention of 
Representative Claim 18 because there is nothing in either reference that teaches or hints in any 
way or even provides a common sense reason for determining a time- scale modification 
playback rate as a function of a measure of CPU availability as required by Representative Claim 
18. As set forth above, Gupta et al. teaches absolutely nothing regarding a measure of CPU 
availability and Hoyer et al. only teaches obtaining and displaying CPU utilization and nothing 
concerning any use thereof. In fact, if one of ordinary skill in the art were to combine Gupta et 
al. and Hoyer et al., that person might display CPU utilization or that person might generate 
alternative versions of the media being rendered that took less CPU utilization to present. Both 
of these methods do not teach or suggest the invention of Representative Claim 18. 

Appellants submit that determining a time-scale modification playback rate as a 
function of a measure of CPU availability to mitigate the problem caused by a non-deterministic 
delay network is surprising and unpredictable . Further, here is no teaching or hint or 
suggestion of any kind in Gupta et al. or Hoyer et al. that this surprising and unpredictable result 
could be obtained or even how it could be obtained. 

In light of the above, Appellants respectfully submit that Issue 1, Grp. 4 Claim 18 
is patentable over Gupta et al. in view of Hoyer et al. 

In sum , in light of the above, Appellants respectfully submit that Claims 10-14 
and 18 are patentable over Gupta et al. in view of Hoyer et al. As such, Appellants respectfully 
request that the rejection of claims 10-14 and 18 under 35 U.S.C. § 103(a) be reversed. 

SUMMARY 

In light of the above, Appellants respectfully submit that claims 10-14 and 18 are 
patentable. Accordingly, Appellants respectfully request that the Examiner's rejections be 
reversed, and the application be allowed at the earliest opportunity. 
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Respectfully submitted, 
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(8) Claims Appendix. 

1. cancelled 

2. cancelled 

3. cancelled 

4. cancelled 

5. cancelled 

6. cancelled 

7. cancelled 

8. cancelled 

9. cancelled 

10. A method for playback of streaming media received over a non- 
deterministic delay network at a client device which comprises: 

receiving the streaming media at the client device, which client device includes a 

CPU; 

playing back the streaming media; 
determining a measure of CPU availability; 

determining a time-scale modification playback rate considering the measure of 
CPU availability and user input time-scale modification playback rate requests; 

utilizing time-scale modification to prepare the streaming media for playback; and 
providing an indication of a current time-scale modification playback rate to the 

user. 

1 1 . The method of claim 10 which further comprises: 

Claims Appendix 
- Al - 



providing an indication of a user requested time-scale modification playback rate. 

12. The method of claim 10 wherein playing back comprises associating a 
time-scale modification playback rate with each entry in a playback buffer queue. 

13. The method of claim 10 wherein the indication comprises a function of 
recent time-scale modification playback rates. 

14. The method of claim 10 wherein the step of utilizing comprises ignoring 
or modifying the user input time- scale modification playback rate when it would interfere with 
providing continuous playback. 

15. cancelled 

16. cancelled 

17. cancelled 

18. A method for playback of streaming media received over a non- 
deterministic delay network at a client device which comprises: 

receiving the streaming media at the client device, which client device includes a 

CPU; 

playing back the streaming media; 
determining a measure of CPU availability; 

determining a time- scale modification playback rate as a function of the measure 
of CPU availability; and 

utilizing time-scale modification to prepare the streaming media for playback. 

19. cancelled 

20. cancelled 
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21. cancelled 

22. cancelled 

23. cancelled 

24. cancelled 

25. cancelled 

26. cancelled 

27. cancelled 

28. cancelled 

29. cancelled 

30. cancelled 

31. cancelled 

32. cancelled 

33. cancelled 

34. cancelled 

35. cancelled 

36. cancelled 

37. cancelled 

38. cancelled 

39. cancelled 
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Evidence Appendix. 

None. 
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Related Proceedings Appendix. 

None. 
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